A computer network typically comprises a plurality of interconnected entities that transmit (“source”) or receive (“sink”) data frames. A common type of computer network is a local area network (“LAN”) that generally comprises a privately owned network within a single building or campus. LANs employ a data communication protocol (LAN standard) such as Ethernet, FDDI, or Token Ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack), such as the Open Systems Interconnection (OSI) Reference Model. In many instances, multiple LANs may be interconnected by point-to-point links, microwave transceivers, satellite hookups, etc., to form a wide area network (“WAN”), metropolitan area network (“ MAN”) or Intranet. These internetworks may be coupled through one or more gateways to the global, packet-switched internetwork generally known as the Internet or World Wide Web (WWW).
Each network entity preferably includes network communication software, which may operate in accordance with Transport Control Protocol/Internet Protocol (TCP/IP). TCP/IP generally consists of a set of rules defining how entities interact with each other. In particular, TCP/IP defines a series of communication layers, including a transport layer and a network layer. At the transport layer, TCP/IP includes both the User Data Protocol (UDP), which is a connectionless transport protocol, and TCP, which is a reliable, connection-oriented transport protocol. When a process at one network entity wishes to communicate with another entity, it formulates one or more messages and passes them to the upper layer of the TCP/IP communication stack. These messages are passed down through each layer of the stack where they are encapsulated into packets and frames. Each layer also adds information in the form of a header to the messages. The frames are then transmitted over the network links as bits. At the destination entity, the bits are re-assembled and passed up the layers of the destination entity's communication stack. At each layer, the corresponding message headers are stripped off, thereby recovering the original message that is handed to the receiving process.
One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a “bridging” function between two or more LANs. Alternatively, a switch may be utilized to provide a “switching” function for transferring information, such as data frames or packets, among entities of a computer network. Typically, the switch is a computer having a plurality of ports that couple the switch to several LANs and to other switches. The switching function includes receiving data frames at a source port and transferring them to at least one destination port for receipt by another entity. Switches may operate at various levels of the communication stack. For example, a switch may operate at Layer 2, which in the OSI Reference Model, is called the data link layer, and includes the Logical Link Control (LLC) and Media Access Control (MAC) sub-layers.
Other intermediate devices, commonly known as routers, may operate at higher communication layers, such as Layer 3, which in TCP/IP networks corresponds to the Internet Protocol (IP) layer. Conventionally, IP data packets include a corresponding header that contains an IP source address and an IP destination address. Routers or Layer 3 switches may re-assemble or convert received data frames from one LAN standard (e.g., Ethernet) to another (e.g., Token Ring). Thus, Layer 3 devices are often used to interconnect dissimilar subnetworks. Some Layer 3 intermediate network devices may also examine the transport layer headers of received messages to identify the corresponding TCP or UDP port numbers being utilized by the corresponding network entities. Many applications are assigned specific, fixed TCP and/or UDP port numbers in accordance with Request For Comments (RFC) 1700. For example, TCP/UDP port number 80 corresponds to the Hypertext Transport Protocol (HTTP), while port number 21 corresponds to File Transfer Protocol (FTP) service.
A process executing at a network entity may generate hundreds or thousands of traffic flows that are transmitted across a network. Generally, a traffic flow is a set of messages (frames and/or packets) that typically correspond to a particular task, transaction or operation (e.g., a print transaction) and may be identified by various network and transport parameters, such as source and destination IP addresses, source and destination TCP/UDP port numbers, and transport protocol.
The treatment that is applied to different traffic flows may vary depending on the particular traffic flow at issue. For example, an online trading application may generate stock quote messages, stock transaction messages, transaction status messages, corporate financial information messages, print messages, data backup messages, etc. A network administrator may wish to apply a different policy or service treatment (“quality of service” or “QoS”) to each traffic flow. In particular, the network administrator may want a stock quote message to be given higher priority than a print transaction. Similarly, a $1 million stock transaction message for a premium client should be assigned higher priority than a $100 stock transaction message for a standard customer.
Computer networks include numerous services and resources for use in moving traffic throughout the network. For example, different network links, such as Fast Ethernet, Asynchronous Transfer Mode (ATM) channels, network tunnels, satellite links, etc., offer unique speed and bandwidth capabilities. Additionally, the intermediate devices also include specific resources or services, such as number of priority queues, filter settings, availability of different queue selection strategies, congestion control algorithms, etc.
Individual frames or packets can be marked so that intermediate devices may treat them in a predetermined manner. For example, the Institute of Electrical and Electronics Engineers (IEEE) describes additional information for the MAC header of Data Link Layer frames in Appendix 802.1p to the 802.1D bridge standard.
FIG. 1A is a partial block diagram of a Data Link frame 100 that includes a MAC destination address (DA) field 102, a MAC source address (SA) field 104 and a data field 106. According to the 802.1Q standard, a user—priority field 108, among others, is inserted after the MAC SA field 104. The user—priority field 108 may be loaded with a predetermined value (e.g., 0–7) that is associated with a particular treatment, such as background, best effort, excellent effort, etc. Network devices, upon examining the user—priority field 108 of received Data Link frames 100, apply the corresponding treatment to the frames. For example, an intermediate device may have a plurality of transmission priority queues per port, and may assign frames to different queues of a destination port on the basis of the frame's user priority value.
FIG. 1B is a partial block diagram of a Network Layer packet 120 corresponding to the Internet Protocol. Packet 120 includes a type—of− service (ToS) field 122, a protocol field 124, an IP source address (SA) field 126, an IP destination address (DA) field 128 and a data field 130. The ToS field 122 is used to specify a particular service to be applied to the packet 120, such as high reliability, fast delivery, accurate delivery, etc., and comprises a number of sub-fields. The sub-fields may include a 3-bit IP precedence (IPP) field and three one-bit flags that signify Delay, Throughput, and Reliability. By setting the flags, a device may indicate whether delay, throughput, or reliability is most important for the traffic associated with the packet. Thus, ToS field 122 facilitates applying various quality of service treatments to packets.
The Common Open Policy Service (COPS) protocol provides one approach for distributing QoS information to a network device. The COPS protocol is defined in RFC 2748, “The COPS (Common Open Policy Service) Protocol,” by J. Boyle et al., January 2000. The use of COPS for resource reservation is described in RFC 2749, “COPS usage for RSVP,” J. Boyle, et al., January 2000. The use of COPS for provisioning is described in the IETF Internet-draft document “draft-ietf-rap-cops-pr-04.txt.” Readers of this patent are assumed to have read the foregoing documents and to understand how to implement their subject matter in a working system.
COPS is a query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). One example of a policy client is a router compatible with Resource Reservation Protocol (RSVP) that must exercise policy-based admission control over RSVP usage. PEPs may be routers, switches, gateways, etc., or any other device that is configured, using one or more software elements or hardware elements, to carry out policy enforcement.
One drawback of the COPS protocol is that it does not provide a mechanism to enable a PDP to download configuration information to a plurality of PEPs with assurance that all the PEPs receive all the configuration information. Thus, there is no way to ensure that specified quality of service information is successfully deployed to an entire network or to a plurality of policy enforcement points. In particular, simultaneous download of configuration information to multiple devices, wherein the configuration information may differ from device to device, is not guaranteed. In one approach, a deployment is sent to and pre-tested by a plurality of target devices. Although this approach increases the likelihood of successfully installing the configuration on all the target devices, there is no guarantee of successful deployment to the entire target device group. Thus, even if such pre-testing is carried out, there is a chance that subsequent actual deployment of the QoS information will not work. For example, if network conditions change between the time of pre-testing and actual deployment, one or more devices may change one or more internal values that resulted in successful pre-testing. As a result, the later deployment may fail.
In yet another approach, a policy decision point could be configured to predict a response of a policy enforcement point to downloaded configuration information, if the PEP provided enough information in a COPS request (REQ) message. However, such a predictive approach has inherent limitations. In particular, a PEP could not necessarily commit to a downloaded configuration due to resource constraints, internal conflicts with other features or other types of configuration, or feature capability constraints.
Examples of resource constraints include insufficient memory, filters, buffers, queues, etc. Resource constraints of a PEP are extremely difficult or impossible for a PDP to predict, even if such constraints are somehow communicated to the PDP by the PEP in a request message. Internal configuration conflicts may vary from one PEP to another and change from a single device version to the following, and therefore would be too complex to predict by the PDP or communicate to the PDP in the request message.
If a PEP device communicates any feature capability constraints within the REQ message using PIB definitions, the PDP can predict failures caused by feature capability constraints, thereby avoiding downloading configuration information for which the PEP cannot commit. However, there is always a chance that the PEP will reject a downloaded configuration due to capability constraints, unless the configuration is previously tested by that PEP.
Moreover, COPS defines limited feedback reporting capabilities for PEPs. If a partial configuration is received, the PEP is required to reject it and report rejection to the sending PDP. However, there is no way for the PEP to report to a PDP that one or more constraints of the PEP are preventing or will prevent proper implementation of a configuration by the PEP.
The consequences of these drawbacks can be severe. If a provisioned device configuration is downloaded to less than all intended devices, or if a partial download of a configuration occurs with respect to a single network device, unpredictable results may occur. At best a minor system malfunction may occur, or a major system failure may occur in a worst case. For example, a partial download of a Differentiated Services configuration may result in inconsistent application of QoS per hop behavior over the network. As another example, sending partial virtual private network configuration information to devices that are intended to form a VPN may result in malfunctioning of the virtual private network. As a third example, a deploying a partial security configuration may result in creating one or more server security holes, or denial of services to innocent users (“insults”).
Based on the foregoing, there is a clear need for a way to deploy quality of service policy information to a plurality of network devices, or to an entire network, with assurance that all devices will receive all applicable policy information.
There is a specific need for a way to adapt the COPS protocol to operate in transactions with multiple policy enforcement points.